<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//Tigris//DTD XHTML 1.0 Transitional//EN"
"http://style.tigris.org/tigris_transitional.dtd">
<html>
<head>
 <style type="text/css">
/* <![CDATA[ */ 
@import "css/readyset.css"; 
@import "css/inst.css";
/*  ]]> */
 </style>

<link rel="stylesheet" type="text/css" href="css/print.css" media="print" />
 <title>Architecture</title>
</head>

<body>
<div class="app">
<div class="readyset">
 <h2><a href="design.html">Design</a> &gt; Architecture</h2>

 <div id="releaseinfo">
 <h3>Release Information</h3>
 <table border="1" cellpadding="3" cellspacing="2" class="axial">
  <tr>
   <th>Project:</th> 
   <td><a href="index.html">PROJECTNAME</a></td> 
  </tr>
  <tr>
   <th>Internal Release Number:</th> 
   <td>X.Y.Z</td> 
  </tr>
  <tr>
   <th>Related Documents:</th> 
   <td>
    <div><a href="srs.html">Software Requirements Specification</a></div>
<!--    <div><a href="design.html">Design</a> &gt;
             <a href="design-scalability.html">Scalability Worksheet</a></div> -->
    <div><a href="design.html">Design</a> &gt;
         <a href="design-security.html">Security Worksheet</a></div>
    <div><a href="glossary.html">Glossary</a></div>
    <div>LINKS TO RELEVANT STANDARDS</div>
    <div>LINKS TO OTHER DOCUMENTS</div>
   </td>
  </tr>
 </table>
 </div> <!-- /releaseinfo -->

 <div class="todo">
  TODO: Answer the questions below to help you define your system
  architecture.  Some example text is provided.
 </div>




 <div id="overview">
 <h3>Overview</h3>

 <dl>
  <dt>What are the most important facts that a developer should know
  about this system architecture?</dt>

  <dd>PARAGRAPH OR BULLETS</dd>


  <dt>What software architecture style is being used?</dt>

  <dd class="sample1">Single-process desktop application (with plug-in extension modules).</dd>

  <dd class="sample2">Client-server with a custom thick-clients and server.</dd>

  <dd class="sample3">2-tier web application: webserver/app-server, database.</dd>

  <dd class="sample4">3-tier web application: webserver, app-server, database.</dd>

  <dd class="sample1">Single web service: app-server, database.</dd>

  <dd class="sample2">Network of web services.</dd>

  <dd class="sample3">Peer-to-peer with/without central server.</dd>

  <dd class="sample4">Pipe-and-filter.</dd>

  <dd class="sample1">Computing grid / distributed servers.</dd>


  <dt>What are the ranked goals of this architecture?</dt>

  <dd>
   <ol>
    <li><a class="def" href="glossary-std.html#dg_easy_integration">Ease of integration</a></li>

    <li><a class="def" href="glossary-std.html#dg_extensibility">Extensibility</a></li>

    <li><a class="def" href="glossary-std.html#dg_cap_match">Capacity matching</a></li>

   </ol>
  </dd>

 </dl>
 </div> <!-- /overview -->




 <div id="components">
 <h3>Components</h3>

 <dl>
  <dt>What are the components of this system?</dt>

  <dd class="sample1">The components of this system are clearly defined in this <a
  href="LINK-TO-MODEL">UML Model with Component Diagram</a>.</dd>

  <dd class="sample2">
   The components of this system are listed below by type:
   <ul>
    <li>Presentation/UI Components
     <ul>
      <li><a href="design-components.html#C-00">C-00: COMPONENTNAME</a></li>
     </ul>
    </li>
    <li>Application Logic Components
     <ul>
      <li><a href="design-components.html#C-10">C-10: COMPONENTNAME</a></li>
     </ul>
    </li>
    <li>Data Storage Components
     <ul>
      <li><a href="design-components.html#C-20">C-20: COMPONENTNAME</a></li>
     </ul>
    </li>
   </ul>
  </dd>
 </dl>
 </div> <!-- /components -->



 <div id="deployment">
 <h3>Deployment</h3>

 <dl>
  <dt>How will the components be deployed to processes and machines?</dt>

  <dd class="sample1">The deployment of components to processes and machines is clearly defined in
  this <a href="LINK-TO-MODEL">UML Model with Deployment
  Diagram</a>.</dd>

  <dd class="sample2">
   The deployment of components to processes and machines is clearly defined below:
   <ul>

    <li>All-in-one server
     <ul>
      <li>Tomcat process
       <ul>
        <li><a href="design-components.html#C-00">C-00: Tomcat web server</a></li>
        <li><a href="design-components.html#C-10">C-10: PROJECTNAME application</a></li>
       </ul>
      </li>
      <li>Database process
       <ul>
        <li><a href="design-components.html#C-30">C-20: COMPONENTNAME</a></li>
       </ul>
      </li>
     </ul>
    </li>
   </ul>
  </dd>

  <dd class="sample3">
   The deployment of components to processes and machines is clearly defined below:
   <ul>

    <li>Load-balanced front-end servers
     <ul>
      <li><a href="design-components.html#C-00">C-01: COMPONENTNAME</a></li>
     </ul>
    </li>
    <li>Back-end server
     <ul>
      <li>JVM process
       <ul>
        <li><a href="design-components.html#C-00">C-00: COMPONENTNAME</a></li>
        <li><a href="design-components.html#C-10">C-10: COMPONENTNAME</a></li>
        <li><a href="design-components.html#C-11">C-11: PLUG-IN COMPONENTNAME</a></li>
        <li><a href="design-components.html#C-12">C-12: PLUG-IN COMPONENTNAME</a></li>
       </ul>
      </li>
      <li>Database process
       <ul>
        <li><a href="design-components.html#C-30">C-20: COMPONENTNAME</a></li>
       </ul>
      </li>
     </ul>
    </li>

   </ul>
  </dd>


  <dt>What aspects/resources of their environment are shared?</dt>

  <dd class="sample1">Everything is on one server so all machine resources are shared
  by all components.</dd>

  <dd class="sample2">All machines share the same bandwidth to the Internet.  All
  machines access the same file server.  So, if one component uses the
  resources heavily, other components may have to wait.</dd>


  <dt>How are requests allocated to redundant or load-balanced
  servers?</dt>

  <dd class="sample1">We are not doing any load-balancing or redundancy for
  fail-over.</dd>

  <dd class="sample2">Load-balancing among front-end servers is handled by a load
  balancing device that we can make very few assumptions about.
  However, once a user session is established, the same front-end
  server will be used for all requests during that session.</dd>


  <dt>What alternative deployment configurations are possible?</dt>

  <dd class="sample1">This is the only possible deployment.</dd>

  <dd class="sample2">The database could be moved to a different machine with a fairly
  simple change to a configuration file.  Otherwise, nothing can be
  changed about the deployment.</dd>

  <dd class="sample3">We have the ability to move the database process to a separate
  machine.  We have the ability to add more front-end servers.  The
  application logic running on the application server cannot be split
  or load-balanced.</dd>

 </dl>
 </div> <!-- /deployment -->




 <div id="integration">
 <h3>Integration</h3>

 <dl>

  <dt>How will components be integrated?  Specifically, how will they
  communicate?</dt>

  <dd class="sample1">All of our code uses direct procedure calls.  The database is
  accessed through a driver.</dd>

  <dd class="sample2">Components within the same process use direct procedure call or
  standard Java events.  Plug-ins are also accessed through a API of
  direct procedure calls and standard events.  Communication with the
  database uses a JDBC driver.  Communication between the front
  end-and back-end servers uses XML-RPC.</dd>


  <dt>What architectural mechanisms are being used to ease future
  extensions or modifications?</dt>

  <dd class="sample1">We could change the database by switching drivers.  Otherwise,
  extensions and modifications can only be done at the design
  level.</dd>

  <dd class="sample2">New front-end components could be added so long as they access
  the back-end the same way.  New plug-in components can be
  dynamically loaded, so long as they satisfy the plug-in API.
  Otherwise, there is no ability to add or exchange components,
  because this architecture uses direct dependencies between its
  components rather than implicit invocation.  Extensions and
  modifications can be made at the design-level, but deploying those
  changes requires recompilation and down-time.</dd>
 </dl>
 </div> <!-- /integration -->



 <div id="scenarios">
 <h3>Architectural Scenarios</h3>

 <div class="todo">
  TODO: Provide architecture scenarios that show how objects will
  communicate across components, processes, and machines.  Focus on
  scenarios where the architecture itself is changing, e.g., system
  startup, shutdown, adding or upgrading components, load balancing or
  fail-over.
 </div>

 <p>The following sequence diagrams give step-by-step descriptions of
 how components communicate during some important usage
 scenarios:</p>

 <ul>
  <li><a href="LINK-TO-DIAGRAM">System startup</a></li>
  <li><a href="LINK-TO-DIAGRAM">System shutdown</a></li>
  <li><a href="LINK-TO-DIAGRAM">SCENARIO NAME</a></li>
 </ul>
 </div> <!-- /scenarios -->



 <div id="checklist">
 <h3>Architecture Checklist</h3>

 <div class="todo">
  TODO: Evaluate your architecture with respect to each of your goals.
 </div>

 <dl>
  <dt>Ease of integration: Have mechanisms been provided for all
  needed types of integration?</dt>

  <dd class="sample1">Yes. In this system, all of the new components are designed to
  work together.  And, the reused components are integrated via fairly
  simple interfaces.</dd>


  <dt>Extensibility: What types of components can be added later and
  how?</dt>

  <dd>See above.</dd>


  <dt>Capacity matching: How has this architecture 
  matched component resource needs to machines?</dt>

  <dd class="sample1">The database can be on a machine with RAID disks and a
  hot-swappable power supply, while the web front-end components can be
  on cheaper machines that could fail individually without causing
  system downtime.  The front-end web servers and application server
  are both CPU-intensive, so they are deployed to different CPUs.  The
  database is disk-intensive, so it can be deployed to the same
  machine as the CPU-intensive application server, with only moderate
  competition for resources.</dd>


  <dt>Has the architecture been communicated to the development
  team and other stakeholders?</dt>

  <dd class="sample1">Yes, everyone understands.  Feedback is
  welcome.</dd>

  <dd class="sample1">No, this is a risk that is noted in the <a
  href="plan.html#risks">Risk Management</a> section.</dd>
   
 </dl>
 </div> <!-- /checklist -->

</div>


 <div class="todo">
  TODO:  Check for <a
  href="http://readyset.tigris.org/words-of-wisdom/design-architecture.html">words
  of wisdom</a> and discuss ways to improve this template.
  Or, evaluate the ReadySET Pro <a title="pro use case template and sample test plan"
  href="http://www.readysetpro.com/">professional architectural design template</a>.
 </div>

<div class="legal1">Company Proprietary</div>

<div class="footnote">
 Copyright &#169; 2003-2004 Jason Robbins.  All rights reserved. <a href="readyset-license.html">License terms</a>.
 Retain this copyright statement whenever this file is used as a
 template.
</div>

</div>
</body>
</html>
